Every integrator has built one of these cells by now: a cobot doing final assembly, a 6-axis robot handling pick-and-place, and two or three servo axes running a shuttle or a rotary index, all sharing floor space and a takt time. The question that never gets asked early enough is architectural, not mechanical: which controller actually owns motion coordination, and how do the pieces talk to each other without turning the cell into a debugging nightmare six months after commissioning.
For years the default answer was “PLC runs everything it can reach,” using PLCopen Part 4 function blocks to sequence servo axes and treating the robot as a black box triggered by handshake bits. That still works fine for plenty of cells. What’s changed is that the OPC UA Robotics companion specification now gives you a real alternative: a standardized information model for robot state, program selection, and motion status that a PLC, a SCADA layer, or an MES can consume without a proprietary driver. That’s a genuine option now, not just a research paper, and it means the “PLC does everything” default deserves to be questioned rather than assumed.
Two different jobs wearing the same hat
PLCopen Part 4 function blocks — MC_MoveAbsolute, MC_MoveLinear, MC_CamIn, and the rest of that family — were built to coordinate servo axes on a single controller with deterministic, cycle-synchronous motion. They assume the PLC’s motion kernel owns interpolation, and they’re extremely good at what they do: gearing, camming, electronic line shafting, multi-axis linear moves where the PLC scan cycle and the motion trajectory generator are tightly bound together.
Robot controllers do something structurally different. A 6-axis articulated robot’s controller is solving inverse kinematics, singularity avoidance, collision zones, and often continuous path blending across a taught or programmed trajectory that the PLC has no visibility into and, frankly, no business trying to recompute. That’s motion planning, not motion sequencing. OPC UA Robotics doesn’t try to replace that planner — it exposes the robot’s state machine, program pointer, and I/O handshakes through a standard address space so the rest of the automation stack can coordinate with it without a vendor-specific fieldbus mailbox interface.
Treating these as competing standards is the wrong frame. PLCopen Part 4 is about who executes interpolation. OPC UA Robotics is about who observes and orchestrates a controller that’s already doing its own interpolation. The collision integrators are hitting isn’t really a standards conflict — it’s that nobody decided in advance which axes in the cell belong to which category.
A decision framework that actually holds up
Three questions do most of the work when you’re laying out the architecture.
How tightly is cycle time coupled across devices?
If a servo axis and a robot arm need to hit position within milliseconds of each other — say, a robot picking off a moving conveyor with no dwell, or a servo-driven fixture that must be at exact position when the robot’s TCP arrives — that’s tight coupling, and it belongs inside one motion-synchronous domain. In practice that means either the servo axis is genuinely camming to the robot’s motion (rare, and usually requires the robot vendor’s own synchronized-motion package rather than PLCopen at all), or you accept a small settle/dwell window and treat the two systems as loosely coupled with handshakes. Real hard real-time coordination across a PLC motion kernel and an independent robot controller, without vendor-specific synchronized motion, is the exception, not the rule — don’t architect assuming you’ll get sub-scan-cycle coordination between two separate controllers unless the robot vendor explicitly supports it.
If the coupling is loose — robot finishes its program, signals done, servo axis indexes, cell continues — that’s exactly the coordination pattern OPC UA Robotics is built for, and trying to force it through PLCopen motion blocks buys you nothing but extra I/O mapping.
How complex is the path, and who taught it?
Servo axes running linear or cammed profiles that an application engineer configures numerically are a natural fit for PLCopen — the path is a small number of parameters, and the PLC’s motion kernel handles it cleanly. Anything involving continuous multi-axis path blending, tool-center-point control, singularity handling, or a path that was taught by jogging a teach pendant belongs in the robot controller, full stop. Don’t let anyone talk you into re-deriving robot kinematics in ladder logic or structured text because it seems architecturally tidier. It isn’t tidier, it’s fragile, and it puts path planning in a system that was never validated for it.
Who owns the safety-rated stop chain?
This is the question shops skip and regret. In a mixed cell, the safety architecture question — which device initiates a Category 0 or Category 1 stop, which safety controller arbitrates between a cobot’s power-and-force-limiting zones and a traditional robot’s hard-guarded cell, and whose safety PLC is the master for the E-stop chain — has to be settled before you decide on motion coordination protocol, not after. OPC UA Robotics and PLCopen are both non-safety, standard communication layers; neither replaces a safety-rated network like a safety fieldbus profile or hardwired safety relays. But the coordination protocol you pick will shape how fast you can react to a safety event functionally, even if the safety chain itself is hardwired or run over a separate safety protocol. If the PLC is the safety master, it needs low-latency, deterministic visibility into robot state — which argues for tight OPC UA Robotics polling or, in demanding cases, hardwired status signals as a backstop rather than relying solely on a non-deterministic OPC UA session.
What this means for how you spec the next cell
Stop treating “PLC or robot controller” as a philosophical question and start treating it as an inventory exercise. Walk the cell axis by axis and ask, for each one: is this camming or interpolating with something else on a millisecond time base, or is it waiting for a done bit? Segment accordingly. Servo axes that are truly kinematically coupled to each other stay under PLCopen Part 4 on one motion controller. Robots — cobot or articulated — keep their own planners and expose state through OPC UA Robotics to the PLC or SCADA layer for supervisory coordination, recipe selection, and status reporting.
The integration risk isn’t in either standard individually. It’s in the seam between them — the handshake logic, the timeout behavior when a robot program stalls mid-cycle, the fallback state when an OPC UA session drops. Budget real engineering time for that seam. It’s where mixed-vendor cells actually fail in commissioning, and no amount of companion-spec compliance from either vendor will paper over a badly designed handshake.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
